Ansible2.2のAWSモジュールを試す
渡辺です。 2016年10月時点では、Ansibleは2.1が最新バージョンですが、2.2系のRCがリリースされはじめました。 Ansible2.2系では、AWS関連のモジュールが大幅に増え、AWSリソースの構成管理としてAnsibleを利用できる範囲が大幅に拡大します。 何回かに分けてAnsible2.2で追加されるモジュールを中心に紹介したいと思います。
Ansible2.2の準備
はじめにAnsible2.2系をインストールしなければなりませんが、幾つか嵌まり場所があります。 結論としては、pipからインストールしますが、次のようにgitリポジトリを指定し、インストールしてください。
pip install git+https://github.com/ansible/ansible.git@v2.2.0.0-0.2.rc2#egg=ansible
本記事を執筆時点では、最新版がv2.2.0.0-0.2.rc2でした。
実際にインストールする場合は、GitHubを確認した上で、バージョン部分を適宜変更してください。
もちろん、pyenvを使い環境をわけておくべきです（pyenv-virtualenvでAnsible2系とAnsible1系を使い分ける）。
また、AWS関連のモジュールを実行するため、boto, boto3も必要なのであわせてインストールしておきます。
pip install boto boto3
ERROR! The requested action was not found in configured module paths.
以下のエラーが発生する場合があります。
ERROR! The requested action was not found in configured module paths. Additionally, core modules are missing.
このエラーでこの記事に辿りついた貴方は、次のようにtar.gzからインストールしていることでしょう。
pip install ansible-2.2.0.0-0.2.rc2.tar.gz
アンインストール後、gitリポジトリを指定してインストールしてください。
ERROR! Missing target hosts
以下のエラーが発生する場合があります。
ERROR! Missing target hosts
このエラーでこの記事に辿りついた貴方は、次のようにzipからインストールしていることでしょう。
pip install ansible-2.2.0.0-0.2.rc2.zip
アンインストール後、gitリポジトリを指定してインストールしてください。
Ansible 2.2で追加されるAWSモジュール
以下のモジュールが追加されます。
- cloudformation_facts
- ec2_asg_facts
- ec2_customer_gateway
- ec2_lc_find
- ec2_vpc_dhcp_options_facts
- ec2_vpc_nacl
- ec2_vpc_nacl_facts
- ec2_vpc_nat_gateway
- ec2_vpc_peer
- ec2_vpc_vgw
- efs
- efs_facts
- execute_lambda
- iam_mfa_device_facts
- iam_server_certificate_facts
- kinesis_stream
- lambda
- lambda_alias
- lambda_event
- lambda_facts
- redshift
- redshift_subnet_group
- s3_website
- sts_session_token
lambda系が気になりますね。
lambda_factsを試してみる
折角なので、lambdaの情報を収集するlambda_factsモジュールを使ってみます。 次のPlaybook（lambda_facts.yml）を作成し、実行してみましょう。
---
- hosts: localhost
connection: local
gather_facts: False
tasks:
- name: List all for a specific function
lambda_facts:
query: all
register: functions
- debug: var=functions
$ ansible-playbook lambda_facts.yml
[WARNING]: Host file not found: /etc/ansible/hosts
[WARNING]: provided hosts list is empty, only localhost is available
PLAY [localhost] ***************************************************************
TASK [List all for a specific function] ****************************************
ok: [localhost]
TASK [debug] *******************************************************************
ok: [localhost] => {
"functions": {
"ansible_facts": {
"lambda_facts": {
"function": {
"log2sns": {
"code_sha256": "****************************=",
"code_size": 832,
"description": "",
"function_arn": "arn:aws:lambda:ap-northeast-1:378384917084:function:log2sns",
"function_name": "log2sns",
"handler": "lambda_function.lambda_handler",
"last_modified": "2016-03-04T01:52:22.978+0000",
"memory_size": 128,
"role": "arn:aws:iam::xxxxxxxxxxxx:role/elb_lambda",
"runtime": "python2.7",
"timeout": 3,
"version": "$LATEST",
"vpc_config": {
"security_group_ids": [],
"subnet_ids": []
}
}
}
}
},
"changed": false
}
}
PLAY RECAP *********************************************************************
localhost : ok=2 changed=0 unreachable=0 failed=0
まとめ
AWSのリソース管理をなにで行うべきかは議論の余地があります。 可能であればAWSのスタンダードであるCloudFormationを利用したいところですが、CloudFormationでは構成管理しにくいリソースもあることは事実です。 特にEC2インスタンスやRDSインスタンスなど、ライフサイクルがCloudFormationと独立せざるを得ない場合などです。 うまくCloudFormationと棲み分けしつつ構成管理するのがベストではと考えています。
EC2の内部についてAnsibleで構成管理を行うのであれば、追加で新しいツールを利用せず、AnsibleでAWSリソースも構成管理できるのがひとつの理想なのではないでしょうか？ 次回以降、各モジュールを紹介していきたいかと思います。
